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FIG. 7 
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INTERNET DOCUMENT MANAGEMENT 
SYSTEM AND METHODS 

FIELD OF THE INVENTION 

Hiis invention relates to apparatus and methods for man- 
aging electronic documents over open networks, such as the 
Internet, to permit users to store, retrieve, and collabora- 
tively manipulate files. 

BACKGROUND OF THE INVENTION 

Document management systems are known that permit 
multiple users to store and retrieve electronic documents on 
a closed client/server architecture network, such as a local 
area network or wide area network. These previously known 
document management systems, such as DOCSFusion, 
available from PCDOCS, Inc., Toronto, Ontario, Canada and 
EDMS 98, available from Documentum, Inc., Pleasanton, 
Calif., require the presence of a client application on each 
node of the network that is to access and manipulate files. 

With the recent rapid expansion of the Internet, the 
opportunity for collaborative efforts has increased many 
fold, as colleagues scattered around the world can rapidly 
transmit files for review and revision using electronic mail 
facilities. While electronic mail systems are useful for 
transmitting relatively small files on the Internet, however, 
large documents often are too large to be handled by typical 
message transfer systems, and can overburden a network. 
Large documents also may exceed the available storage at a 
recipient's site, thus preventing a recipient from storing a 
received document. Electronic mail systems used on open 
systems, such as the Internet, also do not generally address 
security concerns, or permit a transmission to be tracked, as 
is possible with a physical document delivery service (e.g., 
courier). 

Smith U.S. Pat. No. 5,790,790 describes an Internet 
electronic document delivery system, wherein an e-mail 
message contains a direct reference (i.e., a Uniform 
Resource Locator or "URL") to an electronic document 
stored on a server. When a recipient receives the e-mail 
message, the direct reference is used to access the document. 
A drawback of the system described in that patent, is that the 
sending computer must include a specialized client applica- 
tion for interacting with the server. The system described in 
that patent also lacks the kinds of transaction logging and 
accounting functions needed to provide a useful document 
management system. 

The POSTA® system, offered by Tumbleweed Software 
Corporation, Redwood City, Calif., overcomes some of the 
drawbacks of the system described in the foregoing patent. 
For example, the POSTA® system eliminates the need for 
specialized client software for basic document delivery 
operations, and permits the use of a previously known web 
browser, such as Internet Explorer 4.0®, available from 
Microsoft Corp., Redmond, Wash., or Netscape Navigator®, 
Netscape Corporation, Mountain View, Calif. That commer- 
cial system also eliminates use of the direct reference in the 
e-mail message, instead providing a URL for a webpagc that 
provides the user with several options for document deliv- 
ery. The system provides none of the capabilities normally 
associated with a document management system. 

Higley U.S. Pat. No. 5,790,793, like the foregoing Smith 
patent, also describes an Internet electronic document deliv- 
ery system wherein an e-mail message includes a URL 
reference to a document stored in a server. This system 
described in this patent also requires the use of a specialized 
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client application, and is limited to an electronic document 
delivery service. 

While it is known in the art to use an Internet web browser 
to download an electronic document from a website, using, 
5 for example, Hyper Text Transfer Protocol ("HTTP") or File 
Transfer Protocol ("FTP"), there currently do not exist 
document management systems that permit such a file to be 
modified by a user, and uploaded to the system for further 
collaborative retrieval and modification by others. 
10 In view of the foregoing it would be desirable to provide 
a document management system and methods that permit 
electronic documents to be made available for use on open 
systems, such as the Internet, and to be accessed using a 
previously known web browser — without the need for a 
specialized client application. 

It also would be desirable to provide an Internet-based 
document management system and methods that permit 
users to access a plurality of services supported by a 
common Internet-based database, including document 
storage, collaborative file sharing and workflow, document 
delivery and document distribution. 

It further would be desirable to provide an Internet-based 
document management system and methods that permit 
users to selectively or automatically filter electronic docu- 
^ ments during storage to and/or retrieval from, an Internet- 
based storage site. 

It still further would be desirable to provide an Internet- 
based document management system and methods that 
permit users to collaboratively store, retrieve, modify and 
30 then return an electronic document to an Internet-based 
storage site. 

It yet further would be desirable to provide an Internet- 
based document management system and methods that 
enable the transaction logging and accounting functions 

35 needed for multi-user collaborative electronic document 
manipulation, for example, so that revisions to a document 
may be tracked. 

It also would be desirable to provide an Internet-based 
document management system and methods that enable 

40 tracking of transactions performed on a document for billing 
purposes, and which provide needed access-control 
protocols, for example, so that specific users' privileges with 
respect to a document may be defined. 

SUMMARY OF THE INVENTION 

In view of the foregoing, it is an object of this invention 
to provide a document management system and methods 
that permit electronic documents to be made available for 
use on open systems, such as the Internet, and to be accessed 

50 using previously known web browser — without the need for 
a specialized client application. 

It also is an object of the present invention to-provide an 
Internet-based document management system and methods 
that permit users to access a plurality of services supported 

55 by a common Internet-based database, including document 
storage, collaborative file sharing and workflow, document 
delivery and document distribution. 

It is a further object of this invention to provide an 
Internet-based document management system and methods 

so that permit users to selectively or automatically filter elec- 
tronic documents during storage to and/or retrieval from, an 
Internet-based storage site. 

It is another object of the present invention to provide an 
Internet-based document management system and methods 

65 that permit users to collaboratively store, retrieve, modify 
and then return an electronic document to an Internet -based 
storage site. 
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It is a further object of this invention to provide an 
Internet-based document management system and methods 
that enable the transaction logging and accounting capabili- 
ties needed for multi-user collaborative electronic document 
manipulation, for example, so that revisions to a document 
may be tracked. 

It is a still further object of the present invention to 
provide an Internet -based document management system 
and methods that enable tracking of transactions performed 
on a document for billing purposes, and which provide 
needed access-control protocols, for example, so that spe- 
cific users' privileges with respect to a document may be 
defined. 

These and other objects of the present invention are 
accomplished by providing ao Internet-based document 
management system and methods wherein an electronic 
document may be stored on an Internet-accessible server and 
accessed using a previously known web browser, down- 
loaded for review or manipulation, and then returned to the 
server for access by further users. In. accordance with the 
principles of the present invention, the server is programmed 
with several routines that perform numerous functions, 
referred to hereinafter as "services/' that provide a full- 
featured document management system. 

In a preferred embodiment, the document management 
system is programmed to provide a plurality of services 
supported by a common database and document store. These 
services preferably include storage and retrieval services to 
and from an Internet-based storage site, an electronic docu- 
ment delivery service, a collaborative file sharing service 
and a workflow service, and a document distribution service. 
The server also preferably is programmed to perform a 
security function, to verify or define a requestor's ability to 
access an electronic document, a filtering function that 
performs selective or automatic filtering of documents dur- 
ing storage to and/or retrieval from the storage site, and 
accounting functions that enable detailed accounting of, for 
example, usage of storage on the server, number of accesses, 
etc. In addition, the system may permit multiple service 
providers to utilize common document management ser- 
vices of a server, while appearing to end-users as separate 
dedicated websites. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above and other objects and advantages of the 
invention will be apparent upon consideration of the fol- 
lowing detailed description, taken in conjunction with the 
accompanying drawings, in which like references refer to 
like parts throughout, and in which: 

FIGS. 1A and IB are block diagrams illustrating the 
architecture of a document management service (DMS) 
system constructed in accordance with the principles of the 
present invention; 

FIG. 2 is a schematic diagram of the components of DMS 
database 25 of the present invention; 

FIG. 3 depicts an illustrative hierarchy for file storage of 
electronic documents under the control of server computer 
20; 

FIG. 4 is a simplified flowchart depicting the steps of 
using the document management capabilities of DMS sys- 
tem 25 of the present invention; 

FIG. 5 is a detailed flowchart depicting the process of 
storing an electronic document in the DMS system of the 
present invention; 

FIG. 6 is a detailed flowchart depicting the process of 
retrieving a document stored in the DMS system of the 
present invention; 
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FIG. 7 is a flowchart depicting the process of logging a 
storage transaction; 

FIG. 8 is a diagram of the service and service provider 
architecture; 

5 FIG. 9 is a flowchart depicting registration and authenti- 
cation processes; 

FIG. 10 is a flowchart depicting the logon process; 
FIG. 11 is a flowchart depicting a session management 
10 process; and 

FIGS. 12A and 12B are flowcharts depicting the notifi- 
cation request and delivery processes. 

DETAILED DESCRIPTION OF THE 
15 INVENTION 

The present invention is directed to apparatus and meth- 
ods for managing electronic documents over the Internet. 
Specifically, the present invention comprises an Internet- 
accessible server programmed to provide a plurality of 

20 document management services, including document stor- 
age and retrieval, collaborative file sharing and workflow 
services for electronic documents, an electronic document 
delivery service, and a document distribution service. In 
accordance with the principles of the present invention, 

25 these services are supported by a common database system 
that permits interfaces to the multiple services to be accessed 
using previously known web browsers, and without a spe- 
cialized client application. 

^ System Architecture 

Referring to FIGS. 1A and IB, illustrative architecture 
suitable for implementing the system and methods of the 
present invention is described. In FIGS. 1A and IB, this 
architecture comprises personal computers 10 and 11 

3S coupled through an open network, such as Internet 15, to 
document management services ("DMS") system 17. DMS 
system 17 comprises server computer 20, which in turn, 
comprises or is coupled to DMS database 25, store 30, 
notification server 35 and public key infrastructure server 

40 40. 

Personal computers 10 and 11 are connected using dedi- 
cated lines or dial-up connections to the public standard 
telephone network ("PSTN") to an open network, such as 
Internet 15. While Internet 15 is depicted as a single entity, 

45 it will of course be understood that Internet 15 comprises a 
myriad of computer networks connected by bridges, routers, 
etc., and is constantly evolving. As defined herein, the term 
"Interne t" refers not only to the Internet in its present form, 
but also encompasses changes, additions and future embodi- 

50 ments of the Internet. Each of personal computers 10 and 11 
preferably is connected to Internet 15 through an Internet 
Service Provider ("ISF'), and includes a web browser, such 
as the aforementioned Internet Explorer 4.0® or Netscape 
Navigator®. Personal computers may be standalone 

55 computers, or may be connected to the Internet through a 
local area network (not shown). Personal computers 10 and 
11 may be IBM personal computers, or take the form of 
other devices capable of establishing a connection to the 
Internet, including TV set-top boxes, handheld devices, 

60 Personal Digital Assistants (PDAs) or cellular telephones. 
Server computer 20 is coupled to, and communicates 
asynchronously with, Internet 15, and includes a domain- 
specific digital certificate to enable secure communications. 
Server computer 20 preferably is programmed as a web 

65 server, e.g., to run Hyper Text Transfer Protocol ("HTTP') 
and with Document Management Services ("DMS") system 
software constructed in accordance with the present inven- 
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tion. In a preferred embodiment, the DMS software of the stored in the DMS system. Public key infrastructure server 

present invention runs on the web server through a Common 40 ("PKI"), which also may comprise software running on 

Gateway Interface (CGI). server computer 20 or on one or more separate computers 

This enables DMS system 17 to interact with users connected to server computer 20, provides digital certifi- 

through a web browser, rather than requiring specialized 5 cates to users of the DMS system. The digital certificates 

client software. In particular, a user enters information into mav ^sed bv mc uscrs to digitally sign documents for the 

a form displayed in a web browser. The information is purpose of non-repudiation. 

transferred to server computer 20 using HTTP, and is made DMS system 17 of FIG. 1A illustratively is depicted as 

available to the programmed routines executing on server having a single server computer 20, but also may comprise 

computer 20 through the CGI. Alternatively, the DMS 10 multiple server computers for use in high load scenarios. As 

software of the present invention may be implemented as shown in FIG. IB, when more than one server computer is 

"servlets," i.e., routines, typically written in the Java pro- used, load balance appliance 45 may be employed to balance 

gramming language, that run on a web server. Use of servlets traffic between server computers 20A and 20B. Load balance 

also permits users to interact with DMS system 17 through appliance 45 may comprise software running on the server 

a web browser. 15 computers 20Aand 20B. Alternatively, load balance appli- 

Whilc the present invention is described in the context of ance 45 may comprise software running on a separate 

web browsers running on personal computers to access the computer (not shown), which is in turn connected to server 

DMS system, other devices and software may be used. In computers 20A and 20B. 

general, any software capable of communications with the Referring to FIG. 2, DMS database 25 is described in 

DMS system, and of displaying web pages may be used to 20 greater detail. Database 25 includes a plurality of tables 

access the DMS system. Additionally, as used herein, the 61-64 and 66-68 that maintain information on documents 

term "web browser" includes previously known browsing stored in store 30. Each of tables 61-64 and 66-68 may in 

software, as well as "applets", such as Java applets, that may turn consist of multiple tables. Document information tables 

be downloaded from the DMS system, and temporarily 61 have entries for a number of document-related 

executed within the context of the web browser. 25 parameters, including: information on a document's parent 

Database 25, which may be a relational database, stores: document group; information on the document instances; 

data concerning documents controlled by server computer information on the transport method to be used for retrieval 

20 and stored in store 30 (hereinafter, referred to as "meta- of a document instance; information on the priority of the 

data"), such as annotations, instructions, characteristics, etc.; 3Q document; expiration information: the date and time when a 

user and account data; transaction data; notification data; document instance is changed from "active" status to 

and authorization data, all as described in greater detail "archived" status; workflow information for a document 

hereinafter. Database 25 may be implemented on server instance; security information; document rights; and docu- 

computer 20 or on a separate computer connected to server rnent group rights. 

computer 20. 35 User information tables 62 have entries for information 

Store 30 is connected to server computer 20 and stores relating to users registered to access and use the DMS 

electronic documents (or "files"). Store 30 provides a stor- system, including: the name of the user, logon information 

age mechanism for storing electronic documents, and may for toe user, e.g., user ID and password; user notification 

comprise one or more hard drives, optical drives,' RAIDs, information, e.g., notification address and transport type; 

etc., and further may comprise one or more stores supporting 4Q billing code information; information on the user's account, 

different types of storage media. Store 30 also may comprise where each user account is unique to a service account and 

remote storage, in which the file is stored on a remote DMS user; user session information; and user group information, 

server. If multiple stores are used, DMS system 17 prefer- i.e., information on the group of users that the user is a part 

ably includes a configurable algorithm to decide in which of, including the name of the group, the state of the group, 

store a document will be placed, thereby evenly distributing 45 toe group's security information, and document rights for 

document storage among all stores. toe group. 

Store 30 preferably comprises either a relational database, Account information tables 63 have entries for informa- 
where the electronic documents and information about the . lion relating to users registered to access and use the DMS 
document is stored in the relational database, or a file system, including: service provider identification; pricing 
system. If store 30 comprises a relational database, a unique 50 P lan for each service provider; and billing information such 
key to the document is generated and indexed, as may be as the user's credit card number and the billing format (e.g., 
appropriate for storage of smaller files (e.g., <1 KB). If store monthly); an optional customized URL for each service 
30 comprises a relational database, then entries in the provider; a logo for each service provider, to customize the 
relational database may include a storage type, a storage user interface; and license agreement information so that a 
path (i.e., a description of location), a name, a maximum size 55 service provider can customize the license agreement 
and a state value. When store 30 comprises more than one between the service provider and users, 
store, the state value for each store may be set to "active" or Administrative information tables 64 have entries that 
"inactive" and documents cannot be stored in an "inactive" enable a registered user to review and track activity for a 
store. If store 30 comprises file system storage, the file user's account, including: information on the system admin- 
system may assign a unique name to each document and the so istrator's rights; information on logging errors; information 
document is stored directly on the hard drive, optical drive, on logging transactions; and country and language informa- 
etc., as may be appropriate for large files. tion (e.g., for a system running in the United States, the 

Notification server 35, which may comprise software default language is English), 

running on server computer 20 or on one or more separate Notification information tables 66 maintain information 

computers connected to server computer 20, dispatches 65 necessary to generate a notification message, and include 

notifications, e.g., via voice message, e-mail, pager, etc., to entries for: notification transport type, i.e., e-mail, facsimile, 

users of DMS system 17 concerning the status of documents voice, or pager; information on the status of the notification, 



09/04/2003, EAST Version: 1.04.0000 



US 6,584,466 Bl 

7 8 

i.e. pending, sent, failed; the recipient's notification identi- "pending," "active," "archived," "canceled" and "deleted." 

ft cation; priority information; and optionally, the scheduled Each default state change in a document instance is togged 

date/time for delivery. to the DMS database, and may result, for example, in a 

Transaction information tables 67 record data relating to billable transaction, 

each transaction occurring on the DMS system, and include: 5 Document instances with a "pending" state have an active 

the identification of different transaction types; status infor- date/time that specifies the time at which the state of the 

matron for each transaction; and billing information for each document instance should be changed to "active." A "pend- 

transaction type. ing" document is not available to anyone except the Origi- 

Sccurity information tables 68 include entries for nator. 

security-related parameters, such as: the names of Certificate 10 Document instances marked "active" are accessible by all 

Authorities, i.e., trusted third-party organizations that issue Authorized Users. If a document instance has an expiration 

digital certificates (an attachment to an electronic message time, then the status is changed from "active" to "archived" 

used for security purposes); information on different types of when the expiration time is reached. At this point, document 

digital certificates; information on Authorized User certifi- instance rights are removed for all Authorized Users except 

cates; and notarization information. 15 the Originator. 

Referring now to FIG. 3, an illustrative hierarchical Document instances marked "archived" are accessible 
storage scheme for storing electronic documents on store 30 only to the Originator. The state of these documents is 
of DMS system 17 is described. Each user of DMS system changed to "deleted" after a pre-determined amount of time. 
17 preferably has access to one or more document groups At this time, the physical file corresponding to the document 
70, where each document group comprises a collection of 20 instance is removed/deleted from storage and the corre- 
document objects 72 A and 72B. One document may belong sponding document store record is deleted. Document 
to one, many or no document groups. Each document group instances marked deleted are only available for tracking and 
70 has a name, a description, and a service defined type for billing purposes. These document instances are removed 
defining the document type (e.g., word processing file). A from DMS database 25 only when the corresponding trans- 
document group may have one or more parent document 25 action log is billed and removed from database 25. 
groups. The document groups preferably have extensible Document instances are marked "canceled" when an 
property types. Authorized User (typically the Originator) forces a docu- 

Document objects 72 A and 72B represent a generalized ment to expire before the expiration time. Canceled docu- 

high level description of a document, and consist of a. 3Q ment instances then are treated like archived document 

document name. Document objects also may have exten- instances. 

sible property types. DMS system 17 also may provide a notarization feature, 
Document instances 73 A, 73B and 73C correspond to where each document instance is notarized by the DMS 
specific instances of a document, and each include details system. A digital notarization is used to authenticate an 
about the document, a reference to the document, a docu- 35 identifiable set of data at a given time. A simple notarization 
ment state, description, size, priority, encryption type and scheme, for example, involves creating a digital fingerprint 
expiry date. The default document states are "pending," (or digest) of a document, by using a one-way hashing 
"active," "archived" and "deleted." Document states are algorithm, adding a timestamp, and then signing the result- 
extensible by service. A document state log is kept to track ing data with a private key. DMS system 17 may be 
when a document instance has changed state, as described ^ configured to support multiple notarization schemes by 
hereinbelow. assigning a notarization type to each digital notarization. A 
DMS system 17 also preferably supports multiple ver- digital notarization object may be created, containing a 
sions of documents, for example, versions 74A and 74B. A reference to a document, document instance, document 
document version object is employed in document informa- group, notification or transaction, 
tion tables 61 of database 25 and is used to maintain version 45 Document Storaqe And Retrieval Processes 
relationships between document instances of a given docu- Referring now to FIG. 4, the basic processes of storing 
ment. Each document version instance 74A and 74B and retrieving an electronic document to DMS system 17 are 
includes a reference to the parent and child document described. The series of basic steps described with respect to 
instance, a version name and a unique version ID. FIG. 4 involve interaction between an Originator's computer 
Document records are created in DMS database 25 the 50 (e g., personal computer 10), DMS system 17, and one or 
first time a new document is stored on DMS system 17. more Authorized Users (e.g., personal computer 11). Each of 
Document instance records are created when new docu- the services provided by DMS system 17 includes one or 
ments or new versions of existing documents are stored to more of the steps depicted in FIG. 4, and in accordance with 
the DMS system. Document group records may be created the present invention, each of those steps may involve 
when logical collections of documents are stored at the same 55 performing further functions, such as filtering and account- 
time and it is desired to maintain the relationship between ing functions, specific to a particular service. In accordance 
the documents. Also, according to the authorization infor- with the principles of the present invention, billable services 
mation submitted by a document originator, new document are made available on DMS system 17 to a specific user, 
rights, document group rights and document instance rights singly or in combination, by one or more service providers, 
are created for the document. A document store record 60 Preferably, each of the steps described in FIG. 4 is per- 
references a document instance and a store and includes a formed using secure protocols. 

unique key/name to the document's storage location. FIG. 4 is now illustratively described in overview with 

In a preferred embodiment, documents stored in the DMS respect to a collaborative file snaring service of DMS system 

system are monitored by a document state process that 17. In this service, an electronic document to be stored is 

automatically modifies the state of a document instance 65 created by an Originator using a previously known word 

based on its current slate, the active date/time, and expira- processing, image or spreadsheet client application, and then 

tion date/time. States for a document instance include uploaded and stored in DMS system 17. The electronic 
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document then may be retrieved by one or more Authorized 
Users, as defined by the Originator during the storage 
process. After an Authorized User has modified the 
document, it is returned to store 30 of the DMS system. In 
accordance with the principles of the present invention, each 
transaction involving the document is logged in the trans- 
action tables of DMS database 25, for example, for billing, 
reporting, and tracking purposes. 

More particularly, at step 80, an Originator uses a previ- 
ously known client application, such as a word processing, 
image generation application, spreadsheet, etc., to create an 
electronic document. Illustratively, the document may con- 
sist of a business plan and appendices for a start-up com- 
pany. The Originator then connects to the Internet using his 
or her web browser and enters the URL for the DMS system. 
Once connected to the DMS system website, at step 81, the 
Originator initiates a user session with DMS system 17 
using a logon process, described hereinbelow. 

The Originator then fills out appropriate forms indicating 
a desire to upload the previously created electronic docu- 
ment to the DMS system, and at step 82 defines a list of 
Authorized Users who may access the document. The Origi- 
nator specifies the types of access that each Authorized User 
is to receive, and metadata concerning the document (e.g., 
expiration date, etc.). Thus, for example, some Authorized 
Users may be granted access only to retrieve and review a 
document, while others are granted access to retrieve and 
modify the document. The specific access rights granted to 
each Authorized User are recorded in the document tables of 
DMS database 25, and the transaction is logged in the 
transaction tables of DMS database 25. 

At step 83, the Originator requests that the document be 
uploaded and stored in store 30 of the DMS system. Appro- 
priate records are generated in the document tables of DMS 
database 25, and the transaction is logged in the transaction 
tables of DMS database 25. At step 85, the document is 
uploaded, for example, using HTTP or FTP, and stored in 
store 30. During the upload process, at step 84, the document 
optionally may be automatically or selectively filtered in 
accordance with routines appropriate for the service being 
performed. For example, the document may be automati- 
cally compressed or encrypted, or at the Originator's 
request, converted to a particular file format suitable for the 
Authorized Users (e.g., converted from WordPerfect® to 
Microsoft Word). Other forms of filtering may include 
formatting, translating or virus checking. Both the storage 
and filtering step, if performed, are logged to the appropriate 
tables in DMS database 25. 

At step 86, notification server 35 generates notification 
messages to the Authorized Users informing those Users that 
the document is available in store 30. The notification server 
also may provide a notification to the Originator that the 
notifications to the Authorized Users have been sent or 
delivered, as described hereinbelow with respect to FIGS. 
12 A and 12B. Issuance of any notifications to the Originator 
and Authorized Users are logged in the Notification tables 
and Transaction tables of DMS database 25. At any time 
after the document has been stored to store 30 at step 83, the 
Originator may terminate his or her user session. 

Once an Authorized User receives the notification that the 
document is available for retrieval from store 30, for 
example, by receipt an e-mail message or voice message, the 
Authorized User logs into the DMS system using a previ- 
ously known web browser to create a new user session at 
step 87. The Authorized User may then request retrieval of 
the document from store 30, at step 88, and any automatic 
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filtering, or filtering selected by the Authorized User, may be 
performed during the document download process at step 
89. The document is then downloaded to the Authorized 
User at step 90. Each transaction is logged to the appropriate 

5 tables of DMS database 25. 

In the context of collaborative file sharing, the Authorized 
User may either "get" a copy of the document, thus leaving 
the document available for retrieval by other Authorized 
Users to download and modify, or may "check-out" the 

10 document from store 30. If the Authorized User elects to 
"check-out" the document, only that Authorized User has 
the right to later "check-in" the document. Whether an 
Authorized User has rights to "get" or "check-out" a docu- 
ment depends upon the access rights granted by the Origi- 

15 nator when the document is first stored in the DMS system. 
In a preferred embodiment, the Originator retains the rights 
to later change those access rights. As indicated by return 
arrow 91 in FIG. 4, after an Authorized User has checked out 
and modified the document, he or she may check in the 

20 modified document to the DMS system, and the modified 
document is assigned a new version identifier in the docu- 
ment tables of DMS database 25. 

In the context of a workflow service provided by DMS 
system 17, a workflow table may be associated with a 

25 document in DMS database that specifies multiple tasks to 
be performed in sequence by the Authorized Users. In this 
case, the Originator may associate or import a series of task 
descriptions stored in DMS database 25 with a document 
and a list of Authorized Users responsible for performing 

30 those tasks. After an Authorized User retrieves the 
document, performs the task assigned to him or her, and 
returns the document to store 30, notification server 35 
generates and sends an appropriate notification to the Autho- 
rized User responsible for the next task in the workflow. 

35 In the context of electronic document delivery, the Origi- 
nator may specify one or multiple Authorized Users who are 
permitted access to the document. In this case, notification 
server 35 generates appropriate messages to the Authorized 
User(s) via the selected transport mechanism notifying those 
Users that the document is available in store 30. The 
Authorized Users may then initiate User Sessions to retrieve 
the document, including any specified automatic or user 
selected filtering requested for the document. 

45 In the context of a document distribution service, the 
document is made available in store 30 to one or more 
Authorized Users, who may or may not be known to the 
Originator at the time that the document is placed in store 30. 
The Authorized Users may initiate User Sessions to retrieve 

50 the document, including any specified automatic or user 
selected filtering requested for the document. This service 
could be used, for example, to electronically distribute a 
copyrighted book, by permitting users who pay for the book 
to access and download the book. 

55 Referring now to FIG. 5, a detailed flowchart for the 
process of uploading and storing a document in DMS system 
17 is described, corresponding to steps 81-86 of FIG. 4. The 
Originator first logs on and creates a user session as 
described hereinafter with respect to FIGS. 10 and 11. The 

60 Originator now may upload and store one or more electronic 
documents and information pertaining to the Authorized 
Users for those documents to DMS system 17, preferably 
using a secure Internet protocol, such as Secure Socket 
Layer ("SSL") at step 100. 

65 The Originator may "package" a document prior to 
uploading to the DMS system, for example, using a com- 
pression routine, encryption routine, or by adding a digital 
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signature using applications available on the client 
computer, e.g., personal computer 10. Alternatively, such 
"packaging" may be automatically (or selectively, at the 
Originator's request) performed by DMS system 17 as part 
of a' filtering process during upload and storage of the 
document at step 102. 

Where an encryption filtering function is employed, the 
document may be encrypted using a symmetric algorithm 
with a unique session key. As will of course be understood, 
any symmetric cipher may be used to encrypt the file. The 
session key may be generated using unique information 
about the file (e.g., Document Instance ID, User ID, date/ 
time information) and optionally, session specific informa- 
tion provided by the user. In the case where the Originator 
provides information (e.g., a password or code), an Autho- 
rized User attempting to retrieve the file must provide the 
same information to permit the DMS system to regenerate 
the session key. Based on the packaging type (if any) of the 
document and the storage encryption type, the document 
instance encryption type is set. 

At step 101, the Originator may designate the Authorized 
Users for the document, and the access rights to be granted 
to those Authorized Users. The Authorized Users may be 
identified using a public identifier, e.g., User ID, certificate, 
or notification address. The list of Authorized Users may 
include users who are not already registered users of a 
service provided by the DMS system, authorizing those 
non-registered users with selected rights with respect to the 
document. For example, an Authorized User only may be 
allowed to view a document, but not be allowed to edit the 
document. Additionally, an Authorized User may be granted 
access to a document only for a limited period of time. The 
Authorized User's rights also may be implied by the service 
selected. 

Metadata, comprising information about the document 
itself, also is uploaded and stored in the document tables of 
DMS database 25 at step 100. Metadata that the Originator 
may upload into the DMS system includes information on: 
priority; subject; message; expiration date/time of the docu- 
ment; notification scheduling; confirmation notification; a 
password protect flag; access control; and filtering request 
flag. The document and all related data are uploaded and 
stored to DMS system 17 over secure standard protocols 
such as SSL/HTTP and SSL/FTP. 

At step 101, the system determines whether the Originator 
has specified any Authorized Users. If none are specified (or 
all Authorized Users have already been confirmed), the 
document and metadata are stored in the DMS system at step 
103, after any optional automated or requested filtering is 
performed at step 102. Appropriate transactions are logged 
to DMS database 25 at step 104 and a status message is 
returned to the Originator at step 105. 

If the Originator specifies an Authorized User (or there are 
remaining Authorized Users to be confirmed), the system 
determines at step 106 if the specified Authorized User is 
registered. If so, then the DMS authorization system, 
described hereinafter, is updated for that Authorized User to 
reflect the access rights specified by the Originator or 
implied by that service at step 107. At step 108, the Autho- 
rized User then may be sent a notification by notification 
server 35 at his or her notification address. The foregoing 
process is repeated for each Authorized User specified by the 
Originator. 

If the Authorized User is not registered with the DMS 
system, the Authorized User is prc-registered with tempo- 
rary credentials at step 109. If the pre -registered credentials 
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are determined by the system to be trusted credentials at step 
U0, for example, if a digital certificate issued by a Certifi- 
cate Authority (a trusted third-party organization that issues 
digital certificates) is available, the p re-registered Autho- 

5 rized User's credentials are copied to or referenced by the 
DMS system at step 111 and are required for the pre- 
registered Authorized User to access the documents. If the 
credentials are not trusted credentials, a unique introduction 
number is generated and stored in DMS database 25 at step 

10 112. The pre -registered Authorized User then must use this 
introduction number to access the documents. 

At step 113, the pre -registered Authorized User is granted 
the appropriate rights in the DMS authorization system. The 
first time a pre-registered Authorized User is introduced to 

15 a DMS service, an account is created for that Authorized 
User. Alternatively, if the pre-registered Authorized User 
already has been introduced to a DMS service by a regis- 
tered user, the existing pre-registered Authorized User is 
simply given authorization to access the new document. At 

20 step 114, the pre-registered Authorized User is sent an 
introduction message explaining how to access the 
documents, and the entire process is repeated for each new 
Authorized User at step 115. 

At steps 107 and 113, Authorized Users are granted rights 

25 using the DMS authorization system, which defines the 
rights users have on particular document objects, document 
instances and document groups. For example, when DMS 
system 17 is used for a document delivery service, the 
following steps occur: 
A document group is created to logically contain the 

documents to be delivered; 
A document object and document instance are created for 
each document; 

35 Document group rights, document instance rights, and 
document object rights are created for the Originator 
and Authorized User. 
For example, with respect to a document uploaded to the 
DMS system, an Originator may have owner rights, retrieval 

40 rights, viewing rights and the right to revoke access by a 
previously specified Authorized User, while an Authorized 
User may have viewing and retrieval rights. 

Referring now to FIG. 6, the process by which an Autho- 
rized User retrieves a document from DMS system 17 is 

45 described. As described hereinabove for the document stor- 
age process, a document may be filtered during the retrieval 
process, e.g., to uncompress or unencrypt a compressed or 
encrypted document. The first step in document retrieval, at 
step 120, is for an Authorized User to receive a notification 

50 mforming the Authorized User that the document is avail- 
able on store 30. At step 121, the Authorized User logs on 
to the DMS system, for example, using the DMS system 
URL and a previously known web browser to retrieve the 
document. Alternatively, the Authorized User may access 

55 the DMS system using a URL contained in the notification 
informing the Authorized User that the document is avail- 
able on store 30. Once the Authorized User logs on to the 
DMS system, document retrieval follows one of four pos- 
sible scenarios. 

60 In case A, at step 122, the Authorized User is identified by 
the DMS system as a registered user. In this case, the 
Authorized User submits his credentials at step 123. Once 
the credentials are authenticated, the user is provided access 
to the documents and data at step 124. 

65 In case B, at step 126, the Authorized User is identified by 
the DMS system as a pre-registered Authorized User and the 
service which he or she is accessing requires an introduction 
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number. In this case, the user is supplied with the introduc- 
tion number either through a notification message (see step 
112 of FIG. 5) or by the Originator using a separate channel 
of communication. The user then submits the introduction 
number at step 127. Once the introduction number is 
authenticated, the user is provided access to the documents 
and data at step 124. 

In case C, at step 128, the Authorized User is a pre- 
registered Authorized User and the service that he or she is 
accessing does not require credentials. In this case, the 
Authorized User may directly access the documents and data 
at step 124. 

In case D, at step 129, the Authorized User is a pre- 
registered Authorized User with trusted credentials 
(corresponding to step ill of FIG. 5). In this case, the 
pre -registered Authorized User submits the trusted creden- 
tials at 130. Once the credentials are authenticated, the user 
is provided access to the documents and data at step 124. 

In all cases, all of the Authorized User's activities are 
logged in the transaction log at step 125. 

Transaction Logging 

The DMS system of the present invention preferably 
supports an extensible set of transaction types. A core set of 
transaction types is defined by the DMS system and each 
service provided by the DMS system may define additional 
transaction types. Transaction types have the following 
properties: 

Name 

Billing type: "not billable"; "billable by count"; "billable 
by value" 

Each service account may have a separate pricing plan, 
and each pricing plan may have an associated price per 
period (e.g., monthly subscription), as well as a pricing 
mechanism whereby each transaction type is priced for a 
given value of that transaction ("transaction type pricing 
plan"). For example, if the transaction type is document 
storage, then the transaction type pricing plan may include 
the following information: 

Transaction type (e.g., document storage) 

Pricing plan (e.g., monthly) 

Price (e.g., $0.50 per unit) 

Minimum Value (e.g., 0 KB) 

Maximum Value(e.g., 10 KB) 

Minimum chargeable price (e.g., $1) 

Maximum chargeable price (e.g., $5) 

Visibility: Visible or Not visible, identifying whether the 
user can view logged information on this transaction 
type. 

Given the foregoing information, the value of each transac- 
tion may be calculated and logged in the transaction tables 
of DMS database 25 with an associated price. 

Each transaction may be associated to one or more of: 
document; document instance; document group; or a noti- 
fication (i.e., a particular notification message generated by 
the DMS system). Each transaction also may be associated 
with at least one of: a user account or a service account, and 
preferably is limestamped with the date/time of the trans- 
action. Additionally, each transaction may be digitally 
signed by the DMS system. Transactions also may be 
nestable, i.e., each transaction may have a parent transaction 
associated with it. Transactions may be used to form an audit 
trail for a given user, account, document, document instance, 
document group, or notification. Every one of these objects 
preferably has at least one logged transaction linked to it. 

For example, for a New Document transaction in the 
context of a document delivery service, the following data 
may be stored in the transaction information tables of DMS 
database 25: 
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Parent transaction=document delivery 

Transaction type=new document 

Notification ID = null 

Document Instance ID-9812731 
5 Document Group ID-null 

Document ID=2832837 

Account-lD=5632219 

User 1D-3878772 
Q Amount (Value)=l 

Price (Currency)=S0.50 

bate/Time-l2:34:43.99 EST Mar. 1, 1999 

Visible-yes 

Status»active 

15 The transaction links the new document to a document ID 
(for the document object) and a document instance ID (for 
the specific instance or version of this document and its 
related details including a pointer to its storage), the account 
ID, and the user ID of the user who did the transaction. 

20 In accordance with one aspect of the present invention, 
the transaction log may be used to generate a billing state- 
ment for each account user. A billing statement can be 
generated for a particular account and particular statement 
period. In addition, the DMS system of the present invention 

25 also allows for user-defined identifiers (billing codes) to 
track and organize user activity. For example, a lawyer 
storing a contract on DMS system 17 may include as part of 
the metadata for the document an identification of the 
client's billing code. 

30 During the process of generating a billing statement, the 
status of each of the transactions included in the billing 
statement are changed from "active" to "archived." Trans- 
actions marked as "archived" then may be removed from the 
transaction log (for improved search performance of the 

35 main transaction log) and placed into another log (e.g., an 
archived transactions log). Alternatively, transactions 
marked as archived can be automatically set to "delete" after 
a predetermined configurable lifetime. This status change 
from "archived" to "delete" may occur in both the transac- 

40 lion log and the archived transaction log. Transactions set to 
"delete" are automatically deleted after a timeout period. 

Referring now to FIG. 7 the process of logging a storage 
transaction on the DMS system of the present invention is 
described. As explained above, the DMS system offers many 

45 different services, each of which may have transactions that 
are logged and billed. FIG. 7 is a representative example of 
the process of logging one such transaction. 

At step 140, the logging process requires as input: the 
transaction value (amount), transaction type, and pricing 

50 plan. At step 141, the DMS system determines a billing type 
associated with the transaction type. If the transaction is "not 
billable," determined at step 142, the transaction price is set 
to zero at step 143, and transaction visibility is set according 
to the pricing plan at step 144. If the transaction type's 

55 billing type is "by count," determined at step 145, then the 
record for that range is retrieved from DMS database 25 at 
step 146. The transaction price is set at step 147 and 
visibility is set according to the pricing plan at step 148. 
If the billable type is "by value", determined at step 149, 

60 then the transaction type pricing plan is retrieved from DMS 
database 25 at step 150. In an example in which the 
transaction consists of storing a 1.5 MB document to the 
DMS system, the transaction type is "document storage" and 
the value is 1.5 MB. This transaction type is billable "by 

65 value" and there are two priceable value ranges: 0-1 MB and 
>1 MB. The transaction type pricing plan for the first range 
would include the following information: 
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Plan name (e.g. "Gold plan") over Secure Sockets Layers (SSL) protocol, and a response 

Storage by size mav ^e rcturnc d m Hyper Text Markup Language 

Price=$0 50 ("HTML"). A word processor application may make a 

request to DMS system 17 using HTTP over SSL and a 

Minimum Value-0 MB 5 rcsponse may be rctur ncd in Extensible Markup Language 

Maximum Value- 1 MB ("XML"). Each DMS service may respond to requests for 

Minimum Chargeable Price=$0.l5 data using different formats, e.g., HTML, XML, etc. A DMS 

Maximum Chargeable Price-Null service also may respond to requests by structuring the data 

Visdbilitv=visible differently according to a service provider's preferences. 

The traction type pricing plan for the second range 10 Service providers 167 a -167c in FIG. 8 each provide a 

would include the following information: DMS ""M* usm 8 R MS fa accor ?f nCC w,h °f 

aspect of the present invention, DMS system 17 may include 
Plan name (e.g. Gold plan ) customization functions, that permit different service pro- 
Storage by size viders to access a single DMS system, but create the 
Price=S0.25 is appearance of separate dedicated server computers. For 
Minimum Value- 1 MB example, by accessing a document delivery service with a 
Maximum Value=Null service account provided by ACME Document Delivery, the 

„ user will view ACME's corporate logo in the data returned. 

Minimum Chargeable Price-Null ^ may be accomplishcd> for cxamplC} ^ a « logo » 

Maximum Chargeable Price=Null 20 parameter, stored in account information tables 64 (see FIG. 

Visibility-visible 2), which identifies a particular service provider's corporate 

At step 151, the DMS system begins calculating the information to be displayed to a user account administered 

transaction price by setting the initial transaction price to by that service provider. There may be one or many service 

zero. For each value range within the transaction type's providers 167a-c for each of one or more services on a 

value, determined at step 152, the following process is 25 single DMS system. 

repeated: At step 153, it is determined if value >-maximum DMS system 17 thus may host services for many different 
value. If so, the raw price is calculated as (maximum organizations. Users that have a registered service account 
value — minimum value)xprice at step 154. If not, raw price may use DMS system 17 to access any service for which 
is calculated as (value — minimum value)xprice at step 155. they are registered. Moreover, a registered user may have 
If raw price >-maximum chargeable price, determined at 30 more than one DMS service account, enabling that user to 
step 160, raw price is set to maximum chargeable price at use the same service from more than one service provider 
step 161. If raw price <maximum chargeable price and if raw 167a-c or use different services from different service 
price <-minimum chargeable price then raw price is set to providers 167a-c, or any combination thereof. Because a 
minimum chargeable price at step 163. The transaction price service account contains both a service and a service pro- 
is set to transaction price +raw price at step 164. Therefore, 35 vider 167o-c, billable activity may be tracked by service and 
continuing with the example, for a 1.5 MB file, the final by service provider, thus enabling multiple organizations to 
transaction price would be $0.50(1 MB x$0.50)+$0. 125 (0.5 appear to the end-users (i.e., registered users) to have a 
MBx$0.25)-$0.625. "dedicated" virtual DMS service on the same DMS system 

After the process is repeated for each value range, the 17. 

transaction price is set at step 165. Transaction visibility is 40 User Registration and DMS Access 

set according to the pricing plan at step 166, and all of the The user registration and authentication processes for 

information is logged into the transaction log, completing registering as a user of DMS system 17 are now described, 

the logging process. As described hereinabove, many of the services offered by 

Service And Service Provider Architecture the DMS system of the present invention require a user to 

Referring to FIG. 8, an illustrative service and service 45 have a user account, and information on each user account 

provider architecture for DMS system 17 of the present is stored in the account information tables of DMS database 

invention is described. In the context of this disclosure, a 25. In a referred embodiment, a user may obtain a user 

"service provider" is an entity that resells document man- account either by: 1) registration and authentication or 2) 

agement services available on a DMS system constructed in through introduction by another registered user, 

accordance with the principles of the present invention, and 50 Each user account is unique to a service account and user; 

need not be an ISP. information on each service account also is stored in DMS 

DMS system 17 provides and supports a number of database 25. A service account comprises a service, a service 

different services, as described hereinabove. Each service provider, a pricing plan for every transaction the user does 

provides a unique interface to the DMS system and a unique with an account, a limit plan that limits the use of an account 

way of interacting with the DMS system. Illustrative 55 (e.g., a limit on the maximum file size that can be uploaded 

examples of DMS system services include secure document into the DMS system), a feature plan for customizing the 

delivery 168a, secure document storage 1686, secure col- features available for each service (e.g., disabling the sched- 

laborative file sharing 168c, etc. Each service has a unique uled delivery feature of the document delivery service), and 

interface that limits how a user may interact with the DMS billing information (billing address and payment 

system. For example, a user of a storage service cannot 60 information). 

cause DMS system 17 to send a notification to another user, Referring to FIG. 9 the registration and authentication 

whereas such functionality may be automatically included in processes used by a user to gain access to DMS system 17 

a delivery service. are described. At step 170, the registrant accesses the DMS 

The services interfaces also permit users to interact with system registration interface, for example, using a web 

DMS system 17 using client applications specific to the 65 browser to access the DMS system's registration interface 

service to be performed. For example, a web browser may URL. Next, at step 171, the registrant selects a DMS service 

be used to make requests to DMS system 17 using HTTP for which he or she wishes to be registered. At step 172, the 
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DMS determines whether the registrant already has an 
existing DMS service account. 

If the registrant already has a DMS account, registration 
for a new service requires that the registrant provide his or 
her user credentials at step 173 and then authenticate those 5 
credentials at step 180. If the registrant has no pre-existing 
account, determined at step 172, the registrant is requested 
to provide personal information, such as name, address, 
notification address (e.g., e-mail address, telephone number, 
IP address), payment information, etc. at step 174. At step 10 
175, the DMS server computer processes and verifies the 
registration information. If the information is not success- 
fully verified at step 176, the registrant is informed that 
insufficient information has been provided, at step 186, and 
the registrant is requested to resubmit the information. 15 

If the information is successfully verified, the registrant is 
provided with user credentials over a secure link at step 177. 
User credentials, which may consist, for example, of alpha- 
numeric user IDs, alphanumeric passwords, digital 
certificates, and/or notification addresses, permit the user to 20 
securely access documents, upload documents, view autho- 
rized information on documents, digitally sign documents, 
etc. A user's credentials uniquely identify the user to the 
DMS system. At step 178, the registrant is given instructions 
to authenticate his or her credentials. 25 

Once the registrant is issued credentials, or is determined 
to already have credentials, the authentication process 
begins, at step 179. This may be accomplished by the 
registrant accessing the DMS authentication interface by 
inputting the URL associated with the DMS authentication 30 
interface into his or her web browser. Once the registrant is 
successfully authenticated, at step 180, the registrant's new 
service account is ready for use at step 181. If the registrant 
is not successfully authenticated at step 180, an authentica- 
tion failure is logged at step 182. If the number of authen- 35 
tication failures exceeds a predetermined number, at step 
183, the registrant's ability to authenticate is locked for a 
predetermined period of time at step 184. If the number of 
authentication failures does not exceed the predetermined 
safety limit, the registrant is prompted to authenticate again 40 
at step 185. 

Referring now to FIG. 10, after a user has become 
registered and has authenticated his or her credentials with 
the DMS system, the user then may access the services 
provided by the DMS service by logging on to the DMS 45 
system. A user first accesses the DMS logon service at step 
190, for example, using a web browser to access the URL 
associated with the DMS logon service. The user then 
supplies his or her credentials at step 191, and the DMS 
checks to see if the credentials are valid at step 192. If the 50 
credentials are valid, a user session is created at step 193 and 
the user is given access to the DMS system at step 194. 

If the credentials are not valid, a logon security event 
(noting that there has been a failed logon attempt) is logged 
at step 195. The DMS checks to see if the number of logon 55 
security events exceeds a predetermined number at step 196. 
If that number is not exceeded, an error message is sent to 
the user and the user is permitted to retry the logon process 
at step 197. If the number of logon security events exceeds 
the predetermined number, the user is locked out of the 60 
system at step 198 and a message to that effect is sent to the 
user at step 199. If the user makes a request to the DMS 
system after the current session has expired, he or she will 
be asked to logon again. 

Once a user has successfully logged on, a user session is 65 
logged and stored in DMS database 25. A session comprises 
a unique. alphanumeric identifier and a timestamp, and is 
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associated with a specific user account Each request made 
to the DMS after logging in as a registered user must include 
the correct session password or service will be denied and a 
security event will be logged. Successive security events 
cause an account lockout, preventing the user from gaining 
further access to the DMS system. 

HTTP sessions are stateless, so information on these 
sessions must be maintained in database 25. Communica- 
tions to server 20 contains a session identifier number that 
references session information in database 25. Sessions are 
managed by an automatic process, illustrated in FIG. 11, that 
continually monitors the length of a session to determine if 
a current session is longer than a specific, predetermined 
interval. If there is an active session, determined at step 200, 
the DMS system determines if the session length is greater 
than the predetermined interval, at step 201. If the interval 
has been exceeded, the user session is rendered inactive at 
step 202 and a flag to that effect is entered in the corre- 
sponding database entry. The process is repeated at step 203 
for each active session. Alternatively, a user forced logout/ 
exit also may render a user session inactive and the corre- 
sponding database entry is flagged accordingly. * 

Notification Processes 

Referring now to FIGS. 12 A and 12B, the notification 
request and confirmation services available on a preferred 
embodiment of DMS system 17 are described. Notification 
messages are generated by notification server 35 in response 
to various user events. For example, when a registrant 
registers for a DMS service, the registrant receives a noti- 
fication with instructions on authorization, as discussed 
hereinabove with respect to step 178 of FIG. 9. 

As another example, when an Originator has created an 
electronic document and uploaded that document to the 
DMS system, Authorized Users having access to the docu- 
ment may receive a notification that the document is avail- 
able to be retrieved (as discussed with reference to steps 108 
and 114 of FIG. 5), In this case, the notification may contain 
instructions on how the document may be retrieved from the 
DMS system. The notification messages are digital and may 
take the form of an alphanumeric message, digital sound, 
digital image or other digital forms. DMS system 17 there- 
fore preferably supports several types of notification trans- 
ports including e-mail, fax, voice messaging and pager. 

With respect to FIG. 12 A, the notification request process 
performed by DMS system 17 is described. At step 210, a 
notification message is created by notification server 35 
responsive to some user-initiated event. At step 211, a 
notification request is created that contains some or all of the 
following information: (1) the subject of the message; (2) 
the Originator's notification address (e.g., an e-mail 
address); (3) the notification address of the Authorized 
User(s); (4) the priority of the notification (e.g., high, 
medium, or low); (5) the body of the message, including a 
unique notification identifier created by the DMS system; (6) 
optionally, an indication of the date and time that the 
message should be delivered; (7) a status flag (e.g., 
"pending", "sent", or "failed") indicating the status of the 
notification delivery, initially set to "pending"; (8) the trans- 
port type for the notification (e.g., e-mail, voice message, 
etc.); and (9) a retry counter that tracks the number of times 
that a notification request has been processed (initially set to 
zero, and incremented upon each unsuccessful delivery 
attempt until the notification request status is marked 
"failed.") The notification request is queued, at step 212, 
with a status of "pending," in notification information tables 
66 of DMS database 25. 

The notification delivery process is described with respect 
to FIG. 12B. At step 220, the system iterates through the 
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records in the tables with a "pending" flag. At step 221, 
notification server 35 attempts to deliver the notification 
using the specified transport system for that Authorized 
User. DMS system 17 then checks to see if there is a 
transport rejection, at step 222, for example, if notification 
server 35 is not working. If no transport rejection is detected, 
the notification request flag is set to "sent" at step 223, and 
the notification transaction is logged as sent at step 224. 

If a transport rejection is detected, at step 222, a retry 
counter is checked at step 225. If the number of retries does 
not exceed a predetermined limit, the retry counter is incre- 
mented at step 226 and the notification process begins again. 
If the number of retries exceeds the predetermined limit, the 
notification request flag is set to "failed" at step 227, and the 
notification transaction is logged as "failed," at step 228. At 
step 229, the DMS system checks information on the origin 
of the notification request; where the origin of a notification 
request may be either the DMS system or a system user. 

For example, as described hereinabove, when the notifi- 
cation comprises directions for authorization of a new 
registrant, the notification is automatically generated by the 
DMS system. However, if the notification is a notification 
that a document has been stored in store 30 for subsequent 
retrieval by Authorized Users, the notification may be ini- 
tiated at the request of the Originator who uploaded the 
document to store 30. At step 229, if the system determines 
that the origin is a system user (rather than the DMS system), 
a new notification message reporting the failed notification 
delivery attempt is generated and sent to the system user at 
step 230. 

It is possible for a notification to be sent, but for the send 
to be unsuccessful, for example, if the notification recipi- 
ent's e-mail address is incorrect. For this reason, each 
notification transport that delivers notification messages also 
preferably receives messages that notifications have been 
sent successfully but have failed during transport. Each 
notification transport is polled by an automated process for 
any new messages. Upon receiving a failed notification, this 
process determines (if possible) the notification identifier, 
marks the original notification request as "failed" and logs a 
failed notification transaction linked to the original notifi- 
cation request. In addition, if the origin is not the DMS 
system, a notification is generated and sent to the sender 
indicating a failed delivery. 

One skilled in the art will appreciate that the present 
invention can be practiced by other than the described 
embodiments, which are presented for purposes of illustra- 
tion and not of limitation, and the present invention is 
limited only by the claims that follow. 

What is claimed is: 

1. An Internet-based document management system com- 
prising: 

an Internet -based store for storing an electronic docu- 
ment; 

a database programmed to include and access a document 
table for storing information about the electronic docu- 
ment and a transaction table that stores information 
about transactions performed on the electronic docu- 
ment by different users of the Internet-based document 
management system; and 

a server connected to the Internet-based store and the 
database, the server programmed to receive the docu- 
ment from a remote computer using an Internet proto- 
col and store the document in the Internet -based store, 

wherein the server is programmed to provide a plurality of 
services supported by the database, including filtering 
the electronic document before storing the document in 
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the Internet-based store using one or more of: 
compression, decompression, encryption, decryption, 
translation, and formatting. 

2. The Internet-based document management system of 
5 claim 1 wherein the plurality of services comprises at least 

a document storage and retrieval service and an electronic 
document delivery service. 

3. The Internet-based document management system of 
claim 2 wherein the plurality of services further,comprises a 

10 collaborative file sharing service. 

4. The Internet-based document management system of 
claim 2 wherein the document management system provides 
a customization function wherein a user is presented with 

15 corporate information corresponding to one of a plurality of 
service providers employing the document management 
system. 

5. The Internet-based document management system of 
claim 2, wherein the Internet-based store comprises a file 

20 system. 

6. The Internet-based document management system of 
claim 2, wherein the Internet-based store comprises a hier- 
archical storage system. 

7. The Internet-based document management system of 
25 claim 1 wherein the database further comprises an account 

• information table including accounting data, and the server 
is programmed to apply the accounting data to the informa- 
tion stored in the transaction table to determine a price 
reflecting usage of the document management system. 
30 8. The Internet-based document management system of 
claim 1 further comprising a notification server that gener- 
ates and dispatches notifications containing information 
about the electronic document using information stored in 
35 the database. 

9. A method of providing Internet-based document man- 
agement comprising: 
providing an Internet-based store, a database and a server 
connected to the Internet-based store and the database; 
40 accepting a connection from a first remote computer to the 
server using an Internet protocol; 
receiving an uploaded electronic document from the first 
remote computer to the server using an Internet proto- 

45 

generating a record in a document table of the database to 
store information about the electronic document; 

generating a record in a transaction table of the database 
to store information about transactions performed on 
50 the electronic document; 

filtering the electronic document by applying one or more 
of: compression, decompression, encryption, 
decryption, translation and formatting to the document; 

storing the electronic document in the Internet-based 
55 store; 

accepting a connection from a second remote computer to 
the server using an Internet protocol; and 

providing to the second remote computer a plurality of 
60 document management services supported by the data- 
base; 

wherein the transaction table stores information about 
transactions performed on the electronic document by 
multiple users. 

65 10. The method of claim 9 wherein providing to the 
second remote computer a plurality of document manage- 
ment services supported by the database comprises provid 
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ing at least a document storage and retrieval service and an 
electronic document delivery service. 

U. The method of claim 10 wherein providing to the 
second remote computer a plurality of document manage- 
ment services supported by the database further comprises 
providing a collaborative file sharing service. 

12. The method of claim 9 further comprising providing 
a customization function wherein a user is presented with 
corporate information corresponding to one of a plurality of 
service providers employing the document management 
system. 

13. The method of claim 9 wherein the database further 
comprises an account information table including account- 
ing data, the method further comprising applying the 
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accounting data to the record in the transaction table to 
determine a price. 

14. The method of claim 9 wherein storing the electronic 
document in the Internet-based store further comprises gen- 
erating a record in a document table of the database. 

15. The method of claim 9 wherein storing the electronic 
document in the Internet-based store further comprises stor- 
ing the electronic document in a hierarchical storage system. 

16. The method of claim 9 further comprising generating 
and dispatching a notification from the server to the second 
remote computer containing, information about the elec- 
tronic document using information stored in the database. 
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